Aliasing buffers

ABSTRACT

The present invention extends to methods, systems, and computer program products for aliasing buffers. Embodiment of the inventions supporting buffer aliasing through introduction of a level of indirection between a source program&#39;s buffer accesses and the target executable physical buffers, and binding the logical buffer accesses to actual physical buffer accesses at runtime. A variety of techniques for can be used supporting runtime aliasing of buffers, in a system which otherwise disallows such runtime aliasing between separately defined buffers in the target executable code. Binding of logical buffer accesses in the source program to the actual physical buffers defined in the target executable code is delayed until runtime.

CROSS-REFERENCE TO RELATED APPLICATIONS

Not Applicable.

BACKGROUND Background and Relevant Art

Computer systems and related technology affect many aspects of society.Indeed, the computer system's ability to process information hastransformed the way we live and work. Computer systems now commonlyperform a host of tasks (e.g., word processing, scheduling, accounting,etc.) that prior to the advent of the computer system were performedmanually. More recently, computer systems have been coupled to oneanother and to other electronic devices to form both wired and wirelesscomputer networks over which the computer systems and other electronicdevices can transfer electronic data. Accordingly, the performance ofmany computing tasks are distributed across a number of differentcomputer systems and/or a number of different computing environments.

Some runtime environments use buffer aliasing to provide a programmingabstraction. Buffer aliasing abstracts one or more physical buffers intological buffers that each represents a subset of an underlying physicalbuffer. Buffer aliasing enables programmers to develop algorithmswithout concern of whether buffers that are passed as (e.g., input oroutput) parameters to an algorithm belong to different or the samephysical buffers.

However, other runtime environments disallow runtime buffer aliasingbetween separately defined buffers. In these environments, buffer accessis made through reference to the underlying physical buffers.

Further, it may be that portions of software developed for one runtimeenvironment are ultimately executed in a different runtime environment,such as, for example, in multi-processor environments having differenttypes of processors. Thus, a portion of code including buffer aliasinginstructions can be developed for execution in a first runtimeenvironment (e.g., on a general purpose Central Processing Unit (“CPU”))that supports buffer aliasing. However at runtime, the portion of codecan be allocated to for example at a second different runtimeenvironment (e.g., a Graphical Processing Unit (“GPU”)) that disallowsbuffer aliasing. The second runtime environment does not know how toexecute the buffer aliasing instructions. Thus, upon encountering thebuffer aliasing instructions, the second runtime environment can causethe portion of code to stop working as intended, can cause an exception,or can cause some other type of error.

BRIEF SUMMARY

The present invention extends to methods, systems, and computer programproducts for aliasing buffers. A computer system includes a plurality ofprocessors including a first processor type and a second differentprocessor type. The runtime environment for the second processor typedisallows aliasing of physical buffers.

The computer system accesses a program. The program includes source codeof a programming language. The source code is configured for mixedexecution on the first processor type and the second processor type,with at least one portion of the source code targeted for the secondprocessor type. The source code defines one or more physical buffers andincludes instructions for logically accessing the one or more physicalbuffers through a plurality of logical views. Each logical viewcorresponds to a subset of data in a physical buffer.

At least one portion of source code is converted into second code forthe second different processor type. The second code defines a level ofindirection between the logical buffer access and the underlyingphysical buffer access. Execution of the second code is configuredwithin the runtime environment of the second different processor type tobind logical buffer access to the physical buffer using the definedlevel of indirection. The defined level of indirection is used to bindthe logical buffer access to the physical buffer during execution of thesecond code.

This summary is provided to introduce a selection of concepts in asimplified form that are further described below in the DetailedDescription. This Summary is not intended to identify key features oressential features of the claimed subject matter, nor is it intended tobe used as an aid in determining the scope of the claimed subjectmatter.

Additional features and advantages of the invention will be set forth inthe description which follows, and in part will be obvious from thedescription, or may be learned by the practice of the invention. Thefeatures and advantages of the invention may be realized and obtained bymeans of the instruments and combinations particularly pointed out inthe appended claims. These and other features of the present inventionwill become more fully apparent from the following description andappended claims, or may be learned by the practice of the invention asset forth hereinafter.

BRIEF DESCRIPTION OF THE DRAWINGS

In order to describe the manner in which the above-recited and otheradvantages and features of the invention can be obtained, a moreparticular description of the invention briefly described above will berendered by reference to specific embodiments thereof which areillustrated in the appended drawings. Understanding that these drawingsdepict only typical embodiments of the invention and are not thereforeto be considered to be limiting of its scope, the invention will bedescribed and explained with additional specificity and detail throughthe use of the accompanying drawings in which:

FIG. 1 illustrates an example computer architecture that facilitatesaliasing buffers.

FIG. 2 illustrates a flow chart of an example method for aliasingbuffers.

FIG. 3A illustrates using dynamic tags to provide a level on indirection

FIG. 3B illustrates using abstract interfaces and dynamic linking toprovide a level of indirection.

DETAILED DESCRIPTION

The present invention extends to methods, systems, and computer programproducts for aliasing buffers. A computer system includes a plurality ofprocessors including a first processor type and a second differentprocessor type. The runtime environment for the second processor typedisallows aliasing of physical buffers. The computer system accesses aprogram. The program includes source code of a programming language. Thesource code is configured for mixed execution on the first processortype and the second processor type, with at least one portion of thesource code targeted for the second processor type. The source codedefines one or more physical buffers and includes instructions forlogically accessing the one or more physical buffers through a pluralityof logical views. Each logical view corresponds to a subset of data in aphysical buffer.

At least one portion of source code is converted into second code forthe second different processor type. The second code defines a level ofindirection between the logical buffer access and the underlyingphysical buffer access. Execution of the second code is configuredwithin the runtime environment of the second different processor type tobind logical buffer access to the physical buffer using the definedlevel of indirection. The defined level of indirection is used to bindthe logical buffer access to the physical buffer during execution of thesecond code.

Embodiments of the invention include various mechanisms for providing alevel of indirection. In some embodiments, dynamic tags are used toprovide a level of indirection. Dynamic tags can be included ingenerated executable code (e.g., the second code) for multiplexinglogical buffer access to appropriate physical buffer access. In otherembodiments, abstract interfaces and dynamic linking are used to providea level of indirection. Abstract interfaces are included in generatedexecutable code (e.g., the second code) for logical buffer access. Atruntime, the executable code is dynamically linked to appropriatephysical buffer access.

Embodiments of the present invention may comprise or utilize a specialpurpose or general-purpose computer including computer hardware, suchas, for example, one or more processors and system memory, as discussedin greater detail below. Embodiments within the scope of the presentinvention also include physical and other computer-readable media forcarrying or storing computer-executable instructions and/or datastructures. Such computer-readable media can be any available media thatcan be accessed by a general purpose or special purpose computer system.Computer-readable media that store computer-executable instructions arecomputer storage media (devices). Computer-readable media that carrycomputer-executable instructions are transmission media. Thus, by way ofexample, and not limitation, embodiments of the invention can compriseat least two distinctly different kinds of computer-readable media:computer storage media (devices) and transmission media.

Computer storage media (devices) includes RAM, ROM, EEPROM, CD-ROM,solid state drives (“SSDs”) (e.g., based on RAM), Flash memory,phase-change memory (“PCM”), other types of memory, other optical diskstorage, magnetic disk storage or other magnetic storage devices, or anyother medium which can be used to store desired program code means inthe form of computer-executable instructions or data structures andwhich can be accessed by a general purpose or special purpose computer.

A “network” is defined as one or more data links that enable thetransport of electronic data between computer systems and/or modulesand/or other electronic devices. When information is transferred orprovided over a network or another communications connection (eitherhardwired, wireless, or a combination of hardwired or wireless) to acomputer, the computer properly views the connection as a transmissionmedium. Transmissions media can include a network and/or data linkswhich can be used to carry or desired program code means in the form ofcomputer-executable instructions or data structures and which can beaccessed by a general purpose or special purpose computer. Combinationsof the above should also be included within the scope ofcomputer-readable media.

Further, upon reaching various computer system components, program codemeans in the form of computer-executable instructions or data structurescan be transferred automatically from transmission media to computerstorage media (devices) (or vice versa). For example,computer-executable instructions or data structures received over anetwork or data link can be buffered in RAM within a network interfacemodule (e.g., a “NIC”), and then eventually transferred to computersystem RAM and/or to less volatile computer storage media (devices) at acomputer system. Thus, it should be understood that computer storagemedia (devices) can be included in computer system components that also(or even primarily) utilize transmission media.

Computer-executable instructions comprise, for example, instructions anddata which, when executed on a processor, cause a general purposecomputer, special purpose computer, or special purpose processing deviceto perform a certain function or group of functions. The computerexecutable instructions may be, for example, binaries, intermediateformat instructions such as assembly language, or even source code.Although the subject matter has been described in language specific tostructural features and/or methodological acts, it is to be understoodthat the subject matter defined in the appended claims is notnecessarily limited to the described features or acts described above.Rather, the described features and acts are disclosed as example formsof implementing the claims.

Those skilled in the art will appreciate that the invention may bepracticed in network computing environments with many types of computersystem configurations, including combinations having one or more of:personal computers, desktop computers, laptop computers, messageprocessors, hand-held devices, multi-processor systems (includingsystems with a one or more Central Processing Units (“CPUs”) and one ormore co-processors, for example, Graphical Processing Units (“GPUs”) oraccelerators), microprocessor-based or programmable consumerelectronics, network PCs, minicomputers, mainframe computers, mobiletelephones, PDAs, pagers, routers, switches, and the like. The inventionmay also be practiced in distributed system environments where local andremote computer systems, which are linked (either by hardwired datalinks, wireless data links, or by a combination of hardwired andwireless data links) through a network, both perform tasks. In adistributed system environment, program modules may be located in bothlocal and remote memory storage devices.

FIG. 1 illustrates an example computer architecture 100 that facilitatesaliasing buffers. Referring to FIG. 1, computer architecture 100includes code converter 101, physical buffer 102, processor runtime 141and processor runtime 142. Each of the depicted components is connectedto one another over (or is part of) a system bus and/or a network, suchas, for example, a Local Area Network (“LAN”), a Wide Area Network(“WAN”), and even the Internet. Accordingly, each of the depictedcomputer systems as well as any other connected computer systems andtheir components, can create message related data and exchange messagerelated data (e.g., Internet Protocol (“IP”) datagrams and other higherlayer protocols that utilize IP datagrams, such as, Transmission ControlProtocol (“TCP”), Hypertext Transfer Protocol (“HTTP”), Simple MailTransfer Protocol (“SMTP”), etc.) over the system bus and/or network.

In general, code converter 101 is configured to convert code to includeindirection instructions that facilitate buffer aliasing in a processorruntime that otherwise disallows buffer aliasing between separatelydefined buffers. In some embodiments, indirection instructions includingdynamic tags for multiplexing logical buffer access to actual physicalbuffers. In other embodiments, indirection instructions include abstractinterfaces for logical buffer access. The abstract interfaces aredynamically linked to physical buffer access at runtime.

Physical buffer 102 can be a system memory location (e.g., a portion ofRAM), a virtual memory location (e.g., on disk) within computerarchitecture 100, or a memory location in specialized memory accessibleto the second different processor type.

Computer architecture 100 can include a plurality of processor runtimesincluding processor runtime 141 and processor runtime 142. Eachprocessor runtime can correspond to a different processor, such as, forexample, a general purpose processor (e.g., a Central Processing Unit(“CPU”)) or a special purpose processor (e.g., a Graphical ProcessingUnit (“GPU”)). Each processor runtime can be configured with various(and different) properties used when code is executed. For example, someprocessor runtimes natively support buffer aliasing, while otherprocessor runtimes disallow buffer aliasing.

For example, C++ extended for parallel environments provides anabstraction of a device buffer in the form of an “array” or “array_view”type. Instances of “array” or “array_view” types are inputs and outputsof the code to be executed on a device and can be passed as parametersto the device code at runtime. Each array or array_view instance canprovide access to a subset of an actual underlying physical bufferresource (e.g., DirectX® buffer resource when targeting to DirectX®).When generating executable code for a C++ extended for parallelenvironments kernel function, a compiler defines buffer variables foreach array or array_view parameter to the kernel in the generatedexecutable code.

It may be that portions of the C++ extended for parallel environmentscode are translated into High Level Shader Language (“HLSL”) forexecution on a GPU. For example, C++ extended for parallel environmentscan be targeted to a DirectX®/HLSL platform. Thus, C++ extended forparallel environments array or array_view access can be directlytranslated into a corresponding High Level Shader Language (“HLSL”)buffer access. However, DirectX® disallows buffer aliasing. As such,binding the same DirectX® buffer resource to multiple HLSL buffervariables is also disallowed. Thus, users are essentially unable to passarray or array_view instances with the same underlying DirectX® bufferresource as actual parameters to the C++ extended for parallelenvironments kernel at runtime.

FIG. 2 illustrates a flow chart of an example method 200 for aliasingbuffers. Method 200 will be described with respect to the components anddata of computer architecture 100.

Method 200 includes an act of accessing a program, the program includingsource code of a programming language, the source code configured formixed execution on the first processor type and the second differentprocessor type, the source code defining an array or array_view (alogical view of data) that maps to a physical buffer, the source codealso including instructions for logically accessing the physical bufferthrough a plurality of logical views, each logical view corresponding toa subset of data in the physical buffer, at least one portion of thesource code targeted for the second different processor type (act 201).For example, code converter 101 can access higher level code 111. Higherlevel code 111 can be configured for mixed execution in processorruntime 141 (e.g., a CPU environment supporting buffer aliasing) and inprocessor runtime 142 (e.g., a GPU environment disallowing bufferaliasing). For example, other code 114 can be designated for executionin processor runtime 141 and targeted code 112 can be designated forexecution in processor runtime 142. Higher level code 111 can definephysical buffer 102. Logical buffer access instructions 113 abstractaccess to physical buffer 102 through logical views 102A and 102B.

Method 200 includes an act of converting the at least one portion ofsource code into second code for the second different processor type,the second code defining a level of indirection between the logicalbuffer access and the physical buffer (act 202). For example, codeconverter 101 can convert targeted code 112 to include indirectioninstructions 123. Indirection instructions 123 can define a level ofindirection between logical buffer views 102A and 102B and physicalbuffer 102.

Method 200 includes an act of configuring execution of the second codewithin the runtime environment of the second different processor type tobind logical buffer access to the physical buffer using the definedlevel of indirection (act 203). During execution of lower level code121, targeted code 112 can be passed to processor runtime 142. Processorruntime 142 can configure execution of targeted code to bind logicalbuffer access 113 to physical buffer 102 using indirection instructions123. Processor runtime 142 can analyze logical buffer accessinstructions 113 to determine physical buffers (e.g., 102) that areaccessed through logical views (e.g., 102A, and 102B). Processor runtime142 can generate indirection data 131 to assist indirection instructionsin simulating buffer aliasing.

Method 200 includes an act of using the defined level of indirection tobind the logical buffer access to the physical buffer during executionof the second code (act 204). For example, processor runtime 142 canused indirection instructions 123 to bind 103 logical buffer access 113to physical buffer 102 during execution of targeted code 112.Indirection instructions 123 can refer to indirection data 131 to maplogical views 102A and 102B to corresponding locations within physicalbuffer 102.

Various different techniques can be employed by a (e.g., C++ extendedfor parallel environments) compiler and runtime to facilitate bufferaliasing that is otherwise disallowed. For example, techniques can beused to enable programmers of C++ extended for parallel environments topass array or array_view instances with same underlying physicalDirectX® buffer resource as parameters to a C++ extended for parallelenvironments kernel, even if one or more of the kernel parameters aredeclared as writable. As described, aliasing of array or array_viewinstances can be achieved by introducing a level of indirection betweenthe source array's or source array_view's buffer accesses and theunderlying HLSL buffer accesses in the generated executable code. Actualbinding of an array or array_view access to the appropriate HLSL buffervariable happens at runtime.

One technique for implementing indirection is the use of dynamic tags.FIG. 3A illustrates using dynamic tags for a level of indirection.Complier generated code can include branch code 301. When array 302 isreceived, the branch code can execute on a dynamic tag value to selectone of buffers 303, 304, and 306. During runtime, input logical viewsare checked for aliasing and each logical view is assigned a dynamic tagvalue to redirect the logical view accesses in the share to theappropriate physical buffer (311). A compiled shader is launched withgenerated dynamic tag value input (312).

For example, the following program (e.g., higher level code 111)includes buffer aliasing:

void device_kernel(index<1> idx, array<int, 1> f1, array<int, 1> f2) { f2[idx] = f1[idx] + 5; } void main( ) {  array<int, 1> f1(inputData); . . .  device_kernel(f1, f1); }

Using dynamic tags, a compiler (e.g., code converter 121) defines a HLSLbuffer variable corresponding to each array parameter of the sourcekernel. The bindings between the array buffer and the actual HLSL bufferthat it maps to, are read from a dynamic tag table (generated fromanalysis of prior code) passed to the compiled HLSL code at runtime. Thedynamic tag table contains the mapping between the C++ extended forparallel environments array's buffers and the corresponding HLSL buffervariables. For each array access, the compiler generates a switchstatement on the dynamic tag value for that array, with a case statementfor each of the HLSL buffer variables defined in the generated code.

From the example program, a compiler can generate code that uses dynamictags for indirection. For example, a compiler can generate the followingcode from the example program:

array_to_hlsl_buffer_map tag_table[numArrays]; HLSL_buffer buf1, buf2;// One HLSL buffer variable declared for each array parameter int temp1;switch (tag_table[f1]) { case 0: // Index 0 corresponds to HLSL buffer1  temp1 = buf1[idx];   break; case 1: // Index 1 corresponds to HLSLbuffer2   temp1 = buf2[idx];   break; } int temp2 = temp1 + 5; switch(tag_table[f2]) { case 0: // Index 0 corresponds to HLSL buffer1  buf1[idx] = temp2;   break; case 1: // Index 1 corresponds to HLSLbuffer2   buf2[idx] = temp2;   break; }

The runtime (e.g., processor runtime 142) populates the dynamic tagtable by checking each actual array/array_view or parameter forread-write aliasing with other array/array_view parameters passed to thekernel at runtime. If aliasing is detected for that array/array_view,one of the writable arrays/array_views is picked from among the aliasesand the corresponding HLSL buffer variable is bound to the DirectX®buffer underlying the aliased arrays/array_views. Entries for each ofthe aliased arrays/array_views in the array to HLSL buffer map are setto the index (integer ID) of the HLSL buffer variable bound to theDirectX® buffer resource. The HLSL buffer variables corresponding to allthe other aliased arrays/array_views are bound to NULL.

For the example program the table generated is:

Array “f1”→0 (Index of 1^(st) HLSL buffer variable)

Array “f2”→0 (Index of 1^(st) HLSL buffer variable)

Another technique for implementing indirection is the use of abstractinterfaces and dynamic linking FIG. 3B illustrates using abstractinterfaces and dynamic linking for a level of indirection. Compilergenerated code can include a shader using an abstract interface forarray/array_view buffer access (351). During runtime, code is checkedfor aliasing among runtime array/array_view parameters (361). Arrayaccess interface instances are bound to implementations corresponding toappropriate HLSL buffers (362).

When using abstract interfaces and dynamic binding, the compiler definesa HLSL buffer variable corresponding to each array parameter of thesource kernel and an instance of an abstract interface for accessingeach array parameter's underlying buffer. Additionally, concreteimplementations of the array/array_view buffer access interface aregenerated corresponding to each HLSL buffer variable defined in thegenerated code. Each of the instances of the array/array_view bufferaccess interface in the generated code, is bound at runtime to animplementation corresponding to the appropriate HLSL buffer variable(depending on an aliasing check performed on the actual array/array_viewparameters passed to the kernel at runtime).

At runtime (e.g., processor runtime 142), each actual array/array_viewparameter is checked for read-write aliasing with other array/array_viewparameters passed to the kernel. If aliasing is detected for thatarray/array_view, one of the writable arrays/array_views is picked fromamong the aliases and the corresponding HLSL buffer variable is bound tothe underlying DirectX® buffer. Also, the array_buffer access interfacesfor each of the aliased arrays/array_views are bound to the concreteimplementation of the interface corresponding to the chosen HLSL buffervariable. The HLSL buffer variables corresponding to other aliasedarrays/array_views are bound to NULL.

C++ extended for parallel environments provides the abstraction of adevice buffer in the form of an “array” type. Instances of the “array”type are inputs and outputs of the code to be executed on a device andare passed as parameters to the device code at runtime. Each arrayinstance provides access to a subset of the actual underlying physicalDirectX buffer resource. When generating executable code for a C++extended for parallel environments kernel function, a compiler definesbuffer variables for each array parameter to the kernel in the generatedexecutable code. However, since DirectX disallows binding the sameDirectX buffer resource to multiple HLSL buffer variables if any of theHLSL buffer variables are writable, users are unable to pass arrayinstances with the same underlying DirectX buffer resource as actualparameters to a kernel at runtime.

HLSL Dynamic Linking can be used for supporting buffer aliasing. Forexample, if a shader needs to access three buffers as:

RWStructuredBuffer<uint> _GV_buffer_rw_0: register(u0);StructuredBuffer<uint> _GV_buffer_ro_0: register(t0);StructuredBuffer<uint> _GV_buffer_ro_1: register(t1);Instead of generating code to directly read/write the buffers, access isprovided via two interfaces.

One interface abstracts the read-only buffer, the other abstracts theread-write buffer

interface ROBufferInterface {  uint Load(uint idx); }; interfaceRWBufferInterface {  uint Load(uint idx);  void Store(uint idx, uintval); };

For a RWStructuredBuffer, two classes are generated, one implements theROBufferinterface, and one implements the RWBufferinterface:

class BufferClass_0_RO : ROBufferInterface {  uint Load(uint idx) {  return_GV_buffer_rw_0[idx];  } }; class BufferClass_0_RW :RWBufferInterface {  uint Load(uint idx) {   return_GV_buffer_rw_0[idx]; }  void Store(uint idx, uint val) {   _GV_buffer_rw_0[idx] = val;  } };

For a ROStructuredBuffer, one class is generated that implements theROBufferinterface:

class BufferClass_1_RO : ROBufferInterface {  uint Load(uint idx) {  return_GV_buffer_ro_0[idx];  } }; class BufferClass_2_RO :ROBufferInterface {  uint Load(uint idx) {   return_GV_buffer_ro_1[idx]; }

}; Instances of the interfaces are declared:

RWBufferinterface Buffer_(—)0;

ROBufferinterface Buffer_(—)1;

ROBufferinterface Buffer_(—)2;

Other code accesses the buffer via Buffer_(—)0, Buffer_(—)1, andBuffer_(—)2 instead of _GV_buffer_rw_(—)0, _GV_buffer_ro_(—)0, and_GV_buffer_ro_(—)1.

When the runtime detects the aliased input, the runtime detects thecorresponding shader. The runtime then configures binding the Buffer_xto an implementation of the interface. Table 1 depicts an examplemapping between the various different elements:

TABLE 1 Input/output DirectX ® HLSL Interface Runtime binding to a ArrayBuffer Instance class array 0 Buf 0 RWBufferInterface class (RW)Buffer_0 BufferClass_0_RW array 1 Buf 1 ROBufferInterface class (RO)Buffer_1 BufferClass_1_RO array 2 Buf 0 ROBufferInterface class (RO)Buffer_2 BufferClass_0_RO

As depicted in Table 1, array 0 and array 1 use the same underlyingDirectX® buffer (Buf 0). This is an aliasing that runtime detects. Theruntime then binds “array 2” to class BufferClass_(—)0_RO.BufferClass_(—)0_RO implements ROBufferinterface and uses_GV_buffer_rw_(—)0 for “array 2”. As a result, at runtime,_GV_buffer_rw_(—)0 is used for both array 0 and array 2.

A compiler can determine each slot and make the slots available to aruntime for binding to an instance of a class.

Accordingly, embodiments of the inventions supporting buffer aliasingthrough introduction of a level of indirection between the sourceprogram's buffer accesses and the target executable physical buffers,and binding the logical buffer accesses to actual physical bufferaccesses at runtime. A variety of techniques for can be used supportingruntime aliasing of buffers, in a system which otherwise disallows suchruntime aliasing between separately defined buffers in the targetexecutable code. Binding of logical buffer accesses in the sourceprogram to the actual physical buffers defined in the target executablecode is delayed until runtime.

The present invention may be embodied in other specific forms withoutdeparting from its spirit or essential characteristics. The describedembodiments are to be considered in all respects only as illustrativeand not restrictive. The scope of the invention is, therefore, indicatedby the appended claims rather than by the foregoing description. Allchanges which come within the meaning and range of equivalency of theclaims are to be embraced within their scope.

What is claimed:
 1. At a computer system including a plurality ofprocessors and system memory, the plurality of processors including afirst processor type and a second different processor type, the runtimeenvironment for the second different processor type disallowing aliasingof physical data buffers, a method for aliasing a buffer, the methodcomprising: accessing a program, the program including source codeconfigured for mixed execution on the first processor type and thesecond different processor type, the source code defining a physicalbuffer, the source code also including aliasing instructions forlogically accessing the physical buffer through a plurality of logicalviews, each logical view corresponding to a subset of data in thephysical buffer, at least one portion of the source code containing thealiasing instructions targeted for execution in the runtime environmentfor the second different processor type disallowing aliasing of physicaldata buffers; converting the at least one portion of source code intosecond code for the second different processor type, the second codedefining a level of indirection between the logical buffer access andthe physical buffer; configuring execution of the second code within theruntime environment of the second different processor type to bindlogical buffer access to the physical buffer using the defined level ofindirection; and using the defined level of indirection to bind thelogical buffer access to the physical buffer during execution of thesecond code.
 2. The method as recited in claim 1, wherein accessing aprogram comprises accessing a C++ program, the C++ being extended forparallel environments.
 3. The method as recited in claim 1, whereinaccessing a program comprises accessing a program configured for mixedexecution in a Central Processing Unit (“CPU”) runtime and a GraphicalProcessing Unit (“GPU”) runtime.
 4. The method as recited in claim 1,wherein accessing a program comprises accessing a program that includesinstructions for logically accessing one of: Random Access Memory(“RAM”) and virtual memory on a disk.
 5. The method as recited in claim1, wherein converting the at least one portion of source code intosecond code for the second different processor type comprises convertingthe at least portion of source into High Level Shader Language (“HLSL”)code for execution on a Graphical Processing Unit (“GPU”).
 6. The methodas recited in claim 1, further comprising: analyzing the second code tocreate a mapping between C++ extended for parallel environments arraybuffers and corresponding High Level Shader Language (“HLSL”) buffervariables; and wherein using the defined level of indirection to bindthe logical buffer access to the physical buffer comprises using themapping to bind the logical buffer access to the physical buffer access.7. The method as recited in claim 1, wherein converting the at least oneportion of source code into second code for the second differentprocessor type, the second code defining a level of indirection betweenthe logical buffer access and the physical buffer comprises convertingthe at least one portion of source code to use dynamic tags to implementthe level of indirection between the logical buffer access and thephysical buffer.
 8. The method as recited in claim 7, wherein using thedefined level of indirection to bind the logical buffer access to thephysical buffer during execution of the second code comprises using thedynamic tags to multiplex logical buffer access to appropriate physicalbuffer access.
 9. The method as recited in claim 1, wherein convertingthe at least one portion of source code into second code for the seconddifferent processor type, the second code defining a level ofindirection between the logical buffer access and the physical buffercomprises converting the at least one portion of source code to useabstract interfaces for logical buffer access.
 10. The method as recitedin claim 9, wherein using the defined level of indirection to bind thelogical buffer access to the physical buffer during execution of thesecond code comprises dynamically linking to the physical buffer accessduring execution.
 11. At a computer system including a plurality ofprocessors and system memory, the plurality of processors including afirst processor type and a second different processor type, the runtimeenvironment for the second different processor type disallowing aliasingof physical data buffers, a method for aliasing a buffer, the methodcomprising: accessing a program, the program including source codeconfigured for mixed execution on the first processor type and thesecond different processor type, the source code defining a physicalbuffer, the source code also including aliasing instructions forlogically accessing the physical buffer through a plurality of logicalviews, each logical view corresponding to a subset of data in thephysical buffer, at least one portion of the source code containing thealiasing instructions targeted for execution in the runtime environmentfor the second different processor type disallowing aliasing of physicaldata buffers; converting the at least one portion of source code intosecond code for the second different processor type, the second codedefining dynamic tags that provide a level of indirection between thelogical buffer access and the physical buffer access; analyzing thesecond code to create a mapping between the logical buffer access andthe physical buffer access; configuring execution of the second codewithin the runtime environment of the second different processor type tobind logical buffer access to the physical buffer using dynamic tags;and using the dynamic tags to multiplex the logical buffer access to thephysical buffer during execution of the second code.
 12. The method asrecited in claim 11, wherein accessing a program comprises accessing aC++ extended for parallel environments program.
 13. The method asrecited in claim 12, wherein converting the at least one portion ofsource code into second code for the second different processor typecomprises converting the at least portion of source into High LevelShader Language (“HLSL”) code for execution on a Graphical ProcessingUnit (“GPU”).
 14. The method as recited in claim 11, wherein accessing aprogram comprises accessing a program configured for mixed execution ina Central Processing Unit (“CPU”) runtime and a Graphical ProcessingUnit (“GPU”) runtime.
 15. The method as recited in claim 11, whereinaccessing a program comprises accessing a program that includesinstructions for logically accessing one of: Random Access Memory(“RAM”) and virtual memory on a disk.
 16. At a computer system includinga plurality of processors and system memory, the plurality of processorsincluding a first processor type and a second different processor type,the runtime environment for the second different processor typedisallowing aliasing of physical data buffers, a method for aliasing abuffer, the method comprising: accessing a program, the programincluding source code configured for mixed execution on the firstprocessor type and the second different processor type, the source codedefining a physical buffer, the source code also including aliasinginstructions for logically accessing the physical buffer through aplurality of logical views, each logical view corresponding to a subsetof data in the physical buffer, at least one portion of the source codecontaining the aliasing instructions targeted for execution in theruntime environment for the second different processor type disallowingaliasing of physical data buffers; converting the at least one portionof source code into second code for the second different processor type,the second code defining an abstract interface that provides a level ofindirection between the logical buffer access and the physical bufferaccess; configuring execution of the second code within the runtimeenvironment of the second different processor type to bind logicalbuffer access to the physical buffer using a concrete implementation ofthe defined abstract interface; and dynamically linking the abstractinterface to the concrete implementation during execution of the secondcode to facilitate physical buffer access.
 17. The method as recited inclaim 16, wherein accessing a program comprises accessing a C++ extendedfor parallel environments program.
 18. The method as recited in claim17, wherein converting the at least one portion of source code intosecond code for the second different processor type comprises convertingthe at least portion of source into High Level Shader Language (“HLSL”)code for execution on a Graphical Processing Unit (“GPU”).
 19. Themethod as recited in claim 16, wherein accessing a program comprisesaccessing a program configured for mixed execution in a CentralProcessing Unit (“CPU”) runtime and a Graphical Processing Unit (“GPU”)runtime.
 20. The method as recited in claim 16, wherein accessing aprogram comprises accessing a program that includes instructions forlogically accessing one of: Random Access Memory (“RAM”) and virtualmemory on a disk.